home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / Developer Essentials Jul 90 / Programming / MPW Dynamo 3.0 / read.me < prev    next >
Encoding:
Text File  |  1990-04-11  |  5.7 KB  |  144 lines  |  [TEXT/MPS ]
  1. How to install Dynamo and do your first Dynamo build:
  2.  
  3.  
  4. 1)    Copy the Dynamo disk (or folder) contents into a folder called
  5.     "dynamo" on your hard disk.
  6.  
  7.  
  8. 2)    Make an addition to the "UserStartup" file for MPW.  This file is found
  9.     in the MPW folder itself.  You need to make an addition for Dynamo
  10.     something like the following:
  11.  
  12.     #   {dynamo} - Directory that contains dynamo package -- same level as MPW.
  13.                 set dynamo "{MPW}":dynamo:
  14.                 export dynamo
  15.  
  16. This example assumes that you created the Dynamo folder at the same directory
  17. level as MPW.  You can actually put it anywhere you want, as long as the
  18. location is reflected in the UserStartup file.
  19.  
  20.  
  21. 3)    Execute this addition to UserStartup, or restart MPW, so the UserStartup
  22.     addition can take effect.
  23.  
  24.  
  25. 4)    Issue the following duplicate command:
  26.  
  27.         duplicate -y {dynamo}dynamo.includes {MPW}aiigsincludes
  28.  
  29.     You now have the Dynamo include files where AsmIIGS can find them.
  30.  
  31.  
  32. 5)    Copy the file called BUILDAPP.SYSTEM (in the app.builder directory) to
  33.     a ProDOS disk.  BUILDAPP.SYSTEM is a very useful program builder and
  34.     launcher for 8-bit applications.  See the "buildapp.manual" in the
  35.     "appbuilder" directory for details on "BUILDAPP.SYSTEM".
  36.     You can use the following command line to copy BUILDAPP.SYSTEM to a
  37.     ProDOS disk:
  38.  
  39.         duplicateiigs -d -mac :app.builder:BUILDAPP.SYSTEM :
  40.  
  41.  
  42. 6)    The Dynamo sample application should now be buildable.  Use the
  43.     following commands to set the current directory and copy the
  44.     buildapp.text script to your ProDOS disk.
  45.  
  46.         SetDirectory {Dynamo}dynamo.sample:
  47.         duplicate -d buildapp.text buildapp.no.res.fork
  48.         duplicateiigs -d -mac buildapp.no.res.fork buildapp.text
  49.         delete -y buildapp.no.res.fork
  50.  
  51.     The above duplicate is necessary due to an old bug in duplicateiigs
  52.     where the destination file was created with a resource fork if the
  53.     source file had one, even if you specified a data fork only copy.
  54.  
  55. 7)    Now use the MPW menu command to do a full build.  The sample program
  56.     name is "sample" (surprise).  Once this is done, you will have a
  57.     ProDOS disk with everything necessary to execute the Dynamo sample
  58.     program.  Just double-click the BUILDAPP.SYSTEM if you are in the IIGS
  59.     finder, or if you have a IIe, then you will need to put ProDOS on the
  60.     disk as well, so it can boot.
  61.  
  62.  
  63. _________________________________________________________________________________
  64.  
  65.  
  66. Some new stuff and some cool ideas:
  67.  
  68. If you are familiar with previous versions of Dynamo, you will see that a
  69. number of things have changed and have been reorganized.  The structure is
  70. more conducive to multiple-project development.  Since Dynamo is localized
  71. and the include files are available to AsmIIGS just like other include files,
  72. Dynamo version control is easier.  It is no longer so tempting to make a
  73. simple custom change to the Dynamo ruuntime for just one application, and
  74. therefore end up with multiple versions of Dynamo for different projects.
  75.  
  76. Another big change is that the source code for BUILDAPP.SYSTEM is now
  77. included.  This is so that extensions in the application build and launch
  78. process can be done by others to better suit their needs.  Currently,
  79. BUILDAPP.SYSTEM simply moves the code to the bank and memory location
  80. described in the build script.  Some more complex methods might be needed
  81. for more complex applications.  An application may need overlays, for
  82. example.  There may be two blocks of code that actually need to run at
  83. the same location, just at different times.  A revised BUILDAPP.SYSTEM
  84. could put these so-designated segments in auxiliary memory, and then the
  85. application could move them to main memory when needed.
  86.  
  87. For example:  Here is a simple idea for an overlay system:
  88.  
  89. BUILDAPP.SYSTEM could move designated files to aux ram when it is moving
  90. segments around at application launch time.  This could even be done by
  91. using ProDOS to save the range of memory to /RAM5.  When the main
  92. application needs the code segment, it could simply use ProDOS to load it
  93. into main memory.
  94.  
  95. Here's a reasonably simple approach to overlays:  When you want to call
  96. a segment of code that may or may not be in main memory, do a jsr to 
  97. an overlay management routine.  (Dynamic segments kind of work this way
  98. on the IIGS.)  The code would look something like:
  99.  
  100.             sec                        ;Input for overlay code.
  101.             lda        value            ;Input for overlay code.
  102.             ldy        value+1            ;Input for overlay code.
  103.             ldx        mode            ;Input for overlay code.
  104.  
  105.             jsr        overlay
  106.             dc.b    jiffyCoolCode    ;Segment # we want to call.
  107.  
  108. The overlay manager would first save the registers and processor status.
  109. Then it would use the return address on the stack to figure out where the
  110. jiffyCoolCode segment number is in memory.  It would then get this byte
  111. from memory.  Once this is done, the return address would be incremented 
  112. by 1 and pushed back onto the stack.
  113.  
  114. Now that we have the overlay segment #, we would use this to load the
  115. segment from /RAM5.  Once it is loaded, the registers and processor status
  116. would be put back to what they were when the overlay manager was called.
  117. Once this is done, the overlay manager would jump to where the code was
  118. loaded.
  119.  
  120. A little more logic could be added to see if the code segment requested
  121. is already in main memory.  (Old segment # = requested segment #.)  If
  122. it is, then the loading of the code could be skipped.
  123.  
  124. As you can see, doing overlays isn't so tough after all.  A simple
  125. system like this can really free up a lot of main ram on an Apple II.
  126.  
  127. For more readibility, a macro could be used to call the overlay code.
  128. The call might look like:
  129.  
  130.             _jsr    jiffyCoolCode
  131.  
  132. The macro would expand to the calling convention shown above.
  133.  
  134.  
  135.  
  136. Anyrate, given that BUILDAPP.SYSTEM isn't the final solution for
  137. everybody, I supplied the code so that everybody could change it
  138. if they wanted to.
  139.  
  140.  
  141.  
  142.  
  143. Eric Soldan, Apple II DTS
  144.